The most popular design reuse methods are for ASIC designs. This is due to the abundance of gates provided by Moore's Law, allowing such a high level of integration as to place an entire system on a chip (SOC). In 1995, the Dataquest definition of SOC included a compute engine (microprocessor, microcontroller or digital signal processor), at least 100,000 user gates, and significant on-chip memory. Five years later, we still don't find an abundance of systems on an ASIC chip. However, what we are seeing is an increased use of system-level integration (SLI).

The predictions are that by 2003 the bulk of the industry revenue growth will be because of SLI. The existing design reuse methodologies today are closely linked to SOC. In reality it makes more sense to tie design reuse methodology to both SOC and SLI since a formalized design reuse methodology would benefit both SOC and SLI designers.

Systems on a reprogrammable chip

But design reuse isn't just for ASICs; methodologies and tools exist now for FPGAs. FPGAs have changed dramatically since they were first introduced and used as glue logic just 15 years ago. Silicon technology now allows us to build FPGAs consisting of tens of millions of transistors allowing for more features and capabilities in programmable technology. With today's deep-submicron technology, it's possible to deliver over three million usable system gates in a FPGA. Today's average ASIC design operating at 30 to 50 MHz can be implemented in an FPGA using the same RTL synthesis design methodology.

By the year 2003, a state-of-the-art FPGA will exceed 50 million system gates, and will operate at internal speeds far surpassing 200 MHz. Many designs that once could only be implemented in an ASIC due to speed, density, or pricing are converting to a much more flexible and productive FPGA solution.

It's a safe bet that more systems will be implemented in FPGAs in the future, especially given Moore's law and the ingenuity of FPGA R&D engineers. Industry analysts predict that in 2003 FPGAs will begin to replace standard cell ASICs in all but very high volume applications.

Because design reuse is about planning for the future, the term systems-on-a-reprogrammable FPGA is used for SOC implemented in an FPGA. This term is used to define both full and partial system-level designs since the challenges facing these FPGA designers are almost identical. Although it's rare to find entire systems on an FPGA today, there is an increasing amount of SLI designs occurring due to the newer FPGA architectures containing system-level features.

Planning for the future

Most major digital design companies are now in the process of defining (or redefining) their design reuse strategy. This generally includes the creation of an internal design reuse department-similar in structure to the existing EDA Department used to manage CAD tools.

The dramatic improvements in FPGA architectures, pricing, and design tools have made it possible for ASIC and FPGA designers to share a common RTL design methodology. A common RTL design methodology is the basis for a common design reuse methodology.

Today, we have the opportunity to define a reuse strategy that not only co-exists for FPGAs and ASICs, but can also work seamlessly between the two technologies. The decision to include FPGAs in a design reuse strategy must be made up-front because it effects almost all phase of the design reuse process, from design specification to verification planning.

A design reuse strategy is more than RTL code and synthesis. Many companies reusing designs have found more value in the specification and the test structure than the actual RTL design. The good news for a current ASIC user is that many of the elements of a good design reuse methodology can easily be adopted for use with FPGAs with minimal modifications. However, there are challenges in merging and ASIC and FPGA reuse strategy.

Although the two design methodologies continue to merge, there are inherent differences between them allowing for their strengths and weaknesses. Before these challenges are addressed, it's important to understand some of the basic elements of a design reuse strategy as defined by the FPGA Reuse Field Guide by Xilinx and Qualis Design Corp.

Infrastructure

Design reuse doesn't just happen. It takes a champion, or champions, who are responsible for identifying potential reusable design and for managing all aspects of the design reuse process. This infrastructure consists of all the non-technical issues that must be in place before reuse can successfully occur. The first part of infrastructure building is to address the issues that support a clean, best-practice SORC and virtual component (VC) design process (see Figure 1).

Figure 1 - SORC (Systems-on-a-Reprogrammable Chip) design process overview

The overall design process includes areas that aren't ordinarily included in FPGA component designing such as behavioral designing (BEH) and formal verification.

Infrastructure building provides the designers with guidelines that must be followed. These guidelines are often placed in a list and used to grade the VC.

The best designers with the best intentions don't always produce the best designs. Design reuse must be planned. A good reuse infrastructure consists of a good project plan to guide the overall project execution and sufficient financial rewards for when the design is reused. The data must be managed for easy deposit and retrieval.

The good news for a common reuse methodology is that most of the infrastructure for an ASIC is identical to that of an FPGA. When storing the project's files, it's recommended that you use a directory structure that helps you identify whether a FPGA or ASIC was used (see Figure 2).

../bin..			Project-wide scripts/commands
  doc/			System-level specification documents
  board/		Data for board designs
  system/		Data for system designs
  mech/		Data for mechanical designs
  shared/		Data for shared components
  SORC/		Data for FPGA SORC/SLI designs. Readme explaining
				subdirectory contents
	doc/		Specification, data sheets and other documents
	bin/		Scripts/commands specific to the design
	beh/		SoRC behavioral model
	rtl/		SoRC HDL synthesizable models
	syn/		Synthesis scripts and logs
	phy/		Physical (gates) model and SDF data
	verif/		Post-route gate level simulation
	OCB/		On-chip buses used
	VC_firm/	Firm virtual components used. Readme explaining
				subdirectory contents
		impl/	Gate level netlist for the VC (.edn)
		net/	Netlist files (EDIF, NGO, NGC) and implementation
			constraint files
		func_ver/	Functional simulation models (.v, .vhd)
		post_ver/	Post-implementation simulation files
		symbol/	Instantiation templates for simulation models

Using common directory structure makes it easier to locate components and write scripts that are portable. At the project level, there are directories that contain data for all design components for the project. Some "system" designs may not have a physical correspondence and may be a collection of other designs (ASIC, FPGA, and board) artificially connected together to verify a subset of the system-level functionality.

Closely coupled to the infrastructure of design reuse is the design process. All SOC designs should be engineered along a hierarchy of buses: a processor bus for co-processors, a high-performance system bus for major functional blocks, and a slow peripheral bus for low-speed functional components. Developing a corporate standard transactional interface between the bus and the VC allows for the most efficient reuse of a design. A transaction interface isolates the VC from the complexity of the bus. The Virtual Socket Interface Alliance (VSIA) has developed a Virtual Component Interface (VCI) specification that defines a transactional interface. Refer to the VSIA Virtual Component Specification for more details.

Often overlooked are the design reuse specifications, a critical element of design reuse. When interviewed, designers reusing VC often comment that the documentation saves more time than the RTL design.

The VC must be documented enough that another user can understand the functionality, limitations, and characteristics. The original scope of the designer's intent of reuse can greatly help the next designer.

Good specifications can help determine the trade-off between using one VC over another or designing from scratch, and can help in understanding how the components interact.

An FPGA design reuse methodology has some noticeable advantages over that of an ASIC. Many elements of the design reuse methodology mentioned earlier can easily incorporate FPGAs with minimal modifications. Areas such as Infrastructure are comprised of basically identical elements. One of the most noticeable advantages of FPGA technology is the time to market. The most noticeable limitations are performance and design methodology where they have traditionally lagged that of an ASIC (see Figure 3).

Figure 3 - The ASIC versus FPGA Design Flow

One advantage of FPGA technology is the time to market.

When developing a common reuse strategy the greatest challenge is the need for higher speed.

A common reuse strategy is based on RTL synthesis, however, many designers are finding that in order to achieve the highest clock speed, the VC must be made firm. While it's possible to develop an internal reuse strategy that includes firm macros, these won't be portable between FPGA and ASIC technologies. This isn't to say that IP a third party provides can't develop a profitable strategy based on firm IP, especially since they possess intimate knowledge of newer technologies and often have an alternative profit source.

Interconnecting VC in an FPGA

While today's FPGAs aren't suited for a high-speed local processor bus or system bus, they are well suited for implementing the peripheral bus that generally contains a reduced signal interface and features as compared to the system bus. The processor bus and system bus typically resides outside of the FPGA. The bridge between the processor bus and the system bus can be incorporated into the FPGA.

An RTL FPGA design using VCI as defined by the Virtual Socket Interface Alliance (www.vsi.org) is typically too slow for SLI designs requiring over 120 MHz internal speeds. Designs implemented using a formal bus structure typically achieve an internal speed of 50 MHz. Synthesized SLI FPGA designs today averages 50 to 80 MHz and at best 120 MHz. While using VCI improves reusability it's not recommended for FPGA technologies. The technique that is recommended is more of an "ad hoc" communication or interconnection style between VC. The VC is directly connected via switches, providing minimal interconnection in order to reduce routing delays. If the connections between the VC are bi-directional, internal tri-state buffers are used. These methods use minimal protocol and minimal overhead but aren't conducive to being reused.

FPGA coding and synthesis

Fine-grain ASIC architectures have the ability to tolerate a wide range of RTL coding styles while still allowing designers to meet their design goals. Course-grain FPGA architectures are more sensitive to coding styles and design practices. In many cases, paying attention to the vendors coding and synthesis guidelines can improve the system performance anywhere from 10 percent to 100 percent. Existing design reuse methodologies already stress the importance of good coding practices to enhance reusability.

The most common reason why a given design is slower in an FPGA compared to an ASIC is an excessive number of logic levels in the critical path. The course-grain nature of an FPGA generally yields a higher penalty for added logic levels than with ASICs. A logic level in a FPGA is considered to be one combinatorial logic block (CLB) or logic element (LE) delay. These delays are dependent on the speedgrade of the device and are typically only a few nanoseconds.

The Xilinx Alliance Series Synthesis and Simulation Design Guide contains guidelines to help reduce the number of logic levels. Many of these guidelines add registers to improve the overall speed since FPGA architectures like Virtex-E are rich in registers. These techniques include duplicating registers to reduce the fan-out of a critical path, one-hot coding of state machines and pipelining. One of the most common problems found in RTL designs is deeply nested code. Although this coding style isn't recommended even for ASIC devices, there is little penalty when targeting a fine-grain ASIC architecture.

A trend that has been steadily increasing over the last few years is the inclusion of system-level features into FPGA devices. For example, Virtex FPGAs include clocks and clock distribution schemes, carry logic, on-chip memory, memory interfaces, and I/O interfaces. While these features definitely improve the FPGAs ability for SLI and SORC, they are often unique to a specific FPGA device. If the original VC is being implemented in a FPGA device, it's best to utilize these system features and document the device family being used and the design environment.

Verification

Verification is a critical element in improving productivity for large FPGA designs. Well-planned and executed verification strategies are used to build trust for future designers. The verification plan is the primary tool for avoiding an ad-hoc verification process and enables the team to properly plan and schedule verification engineering efforts. However, this is an area that is most often skipped in FPGA designing. For FPGA Design Reuse to be effective, designers will need to adopt a structured verification process consisting of verification planning, specification, reusable testbenches, and HDL simulation. As the complexity of FPGA SLI increases, tools such as Timing Analysis and Formal Verification also need to be adopted.

Designers are using FPGAs to replace gate arrays today, and in the near future FPGAs will be used for designs now done with standard cell technology.

Design reuse will be the catalyst for system-level integration and FPGA SLI designers will be faced with the same productivity issues as ASIC designers. As the SLI trend continues, more designs will be shared between ASIC and FPGA.

Carol Fields is currently a design methodologist for the IP Solutions Division at Xilinx. She is the primary author of the first edition of the Xilinx FPGA Synthesis Design Guide, Synthesis Guidelines for EDA Vendors, and more recently co-authored the FPGA Reuse Field Guide in cooperation with Qualis Design Corp.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to mikem@isdmag.com